System and method for distributed concurrent version management

ABSTRACT

A system for distributed concurrent version management. The system includes a first server, a second server, and a first client. The first server has a first database including a file. The second server has a second database including a file copy corresponding to the file, a data replication module, and a connection detection module. When the first client wants to replace the file copy in the second server with an updated file, the file copy is replaced by the updated file when the first server and the second server are connected. Then, the updated file is copied to the first server by the data replication module, and the file in the first database is replaced by the updated file.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to a file management system andmethod, and particularly to a system and method for distributedconcurrent version management that maintains the consistency of filecopies on different servers, so as to reduce the connection cost whenaccessing a single server.

[0003] 2. Description of the Related Art

[0004] In conventional file management and concurrent version systemssuch as a source code management system, all source codes are storedinto a single server that can provide functions to manage the sourcecodes. Clients may connect to the server to access the source codesthrough networks to update or modify the codes. The server can maintainthe validity of the source codes by employing appropriate authorizationmanagement.

[0005]FIG. 1 is a schematic diagram illustrating a conventional filemanagement system. As shown in FIG. 1, all files are stored in thedatabase 101 of the server 100. To access files on the server 100, usersmay employ client 110 (120) to connect to the server 100 and accessfiles in the database 101 through networks. The client 110 (120) andserver 100 are constructed as a client-server-based system by employinga concurrent version management system, such as the VSS (VisualSourceSafe), thus the server 100 has the ability to manage the database101 with authorization.

[0006] Since all clients must connect to the same server to accessfiles, the system load is rapidly raised if a large number of clientsconnect to the server at the same time. Further, the cost ofconstructing networks or dedicated lines is expensive for enterpriseswith branches in different countries.

SUMMARY OF THE INVENTION

[0007] It is therefore an object of the present invention to provide asystem and method for distributed concurrent version management thatmaintains the consistency of file copies on different servers, so as toreduce the connection cost when accessing a single server.

[0008] To achieve the above objects, the present invention provides asystem and method for distributed concurrent version management.According to one embodiment of the invention, the system includes afirst server, a second server, and a client B (first client).

[0009] The first server has a first database including a file. Thesecond server has a second database including a file copy correspondingto the file in the first database, a data replication module, and aconnection detection module. The connection detection module detects theconnection status between the first server and the second server. Whenthe client B wants to replace the file copy in the second server with anupdated file, the file copy is replaced by the updated file if theconnection status is connected. Then, the file copy in the seconddatabase is replaced by the updated file, and the updated file in thesecond database is copied to the first server by the data replicationmodule to replace the file and the file in the first database isreplaced by the updated file.

[0010] Further, the system time is adjusted between the second serverand the client B when replacing the file copy in the second server withan updated file when connected, and a time tag according to the updatedsystem time is labeled after the file copy is replaced by the updatedfile.

[0011] The time tag corresponding to the updated file is furthercompared to a new time tag corresponding to the file in the first serverbefore the file is replaced by the updated file. The file is replaced bythe updated file if the time tag is later than the new time tag, thatis, if the time tag is generated later than the new time tag. Otherwise,the file is not replaced by the updated file.

[0012] In addition, a client A (second client) cannot update the file inthe first server while the file copy is being updated by the client B.When disconnection status is detected, the client B can update the filecopy in the second server, but the client A cannot update the file inthe first server.

[0013] According to another embodiment of the invention, a method fordistributed concurrent version management is provided. The method issuitable for use in a system with a first server having a file, a secondserver having a file copy corresponding to the file, and a client B.

[0014] First, the connection status between the first server and thesecond server is detected. When the client B wants to replace the filecopy in the second server with an updated file, the file copy isreplaced by the updated file when the connection status is connected.Then, the updated file is copied to the first server and the file isreplaced by the updated file.

[0015] Further, system time is adjusted between the second server andthe client B if the client B wants to replace the file copy in a secondserver with an updated file when connected and a time tag according tothe updated system time is labeled after the file copy is replaced bythe updated file.

[0016] The time tag corresponding to the updated file is furthercompared to a new time tag corresponding to the file in the first serverbefore the file is replaced by the updated file. The file is replaced bythe updated file if the time tag is later than the new time tag.Otherwise, the file is not replaced by the updated file.

[0017] Similarly, a client A cannot update the file in the first serverwhen the file copy is updated by the client B. When the first server andsecond server are disconnected, the client B can update the file copy inthe second server, but the client A cannot update the file in the firstserver.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The aforementioned objects, features and advantages of thisinvention will become apparent by referring to the following detaileddescription of the preferred embodiment with reference to theaccompanying drawings, wherein:

[0019]FIG. 1 is a schematic diagram illustrating the conventional filemanagement system;

[0020]FIG. 2 is a schematic diagram showing the architecture of thesystem for distributed concurrent version management according to theembodiment of the present invention; and

[0021]FIG. 3 is a flowchart illustrating the operation of the method fordistributed concurrent version management according to the embodiment ofthe present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0022]FIG. 2 is a schematic diagram showing the architecture of thesystem for distributed concurrent version management according to theembodiment of the present invention.

[0023] According to the embodiment of the invention, the system fordistributed concurrent version management includes a first server 200, aclient A (second client) 210, a second server 300, and a client B (firstclient) 310.

[0024] The first server 200 and the second server 300 have the samecomponents. The first server 200 has a first database 201 including afile (not shown in FIG. 2), a data replication module 202, and aconnection detection module 203. The data replication module 202monitors the status of the first database 201. When the data in thefirst database 201 is updated, the data replication module 202 copiesthe updated data to another server. The connection detection module 203detects the connection status between the first server 200 and thesecond server 300.

[0025] Similarly, the second server 300 has a second database 301, adata replication module 302, and a connection detection module 303. Thesecond database 301 includes a file copy (not shown in FIG. 2)corresponding to the file in the first database 201 of the first server200. The file copy is the same as the file, and the file and the filecopy may be source codes.

[0026] The data replication module 302 monitors the status of the seconddatabase 301. When the data in the second database 301 is updated, thedata replication module 302 copies the updated data to another server.The connection detection module 303 detects the connection statusbetween the second server 300 and the first server 200.

[0027] The first server 200 provides services, such as file access, tothe client A 210, and the second server 300 provides services to theclient B 310. It should be noted that the server requested by the clientcan be determined according to the distance. For example, the client B310 in one country may connect to the second server 300 and the client A210 in another country may connect to the first server 200 if the firstserver 200 is in the second country and the second server 300 is in thefirst.

[0028] When the client B 310 wants to replace the file copy in seconddatabase 301 of the second server 300 with an updated file (not shown inFIG. 2), the connection status is detected by the connection detectionmodule 303. If the second server 300 and the first server 200 areconnected, the system time is adjusted between the second server 300 andthe client B 310. That is, the time of the client B 310 is set as thesystem time of the second server 300.

[0029] Then, the file copy in second database 301 of the second server300 is replaced by the updated file, and a time tag according to theupdated system time is labeled after the file copy is replaced by theupdated file.

[0030] Once the data replication module 302 monitors the update of thesecond database 301, the time tag corresponding to the updated file iscompared to a time tag (new time tag) corresponding to the file in thefirst server 200.

[0031] The updated file is copied to the first server 200 by the datareplication module 302 and the file is replaced by the updated file ifthe time tag is later than the new time tag, that is, if the time tag isgenerated later than the new time tag. Otherwise, the updated file isnot copied to the first server 200 and the file in the first server 200is not replaced by the updated file.

[0032] It should be noted that the purpose of adjusting the system timeat the beginning of replication is to make sure that the client B 310uses the same system time as the second server 300 in replication. Tocompare the time tags is to make sure that the latest updated file iskept in the database so as to maintain the accuracy of the database.

[0033] Since the first server 200 and the second server 300 have thesame components, and that the relation between the client A 210 and thefirst server 200 and the relation between the client B 310 and thesecond server 300 are the same, when successful connection between thesecond server 300 and the first server 200 are detected by theconnection detection module 203, the components in first server 200 workin the same manner as those in second server 300, but the roles of thefirst and second server 200 and 300 are interchanged.

[0034] In addition, the client A 210 cannot update a specific file inthe first server 200 when the copy of the specific file in the secondserver 300 is being updated by the client B 310. Similarly, the client B310 cannot update the file copy in the second server 300 when the filein the first server 200 is being updated by the client A 210.

[0035] The client B 310 can update the file copy in the second server300 if disconnection is detected between the first server 200 and thesecond server 300. The client A 210, however, cannot update the file inthe first server 200 if the first server 200 and the second server 300are disconnected. In this case, the second server 300 is designated asmaster server and the first server 200 is the secondary server. Forconsistence of database file versions, the master server may providefull functions to clients if the master and secondary servers aredisconnected, but the secondary server provides only limited functions,such as reading without updating.

[0036] It should be noted that the clients and the servers (the client A210 and first server 200, and the client B 310 and second server 300)may be constructed as client-server-based systems by employing aconcurrent version management system, such as the VSS (VisualSourceSafe), thus the servers (200 and 300) can manage the database (201and 301) with suitable authorization. As described above, the secondserver 300 and the first server 200 can be constructed as the masterserver and the secondary server respectively by employing the concurrentversion management system, VSS. Further, the data replication modules(202 and 302) may be constructed according to Microsoft's FileReplication Service (FRS).

[0037]FIG. 3 is a flowchart illustrating the operation of the method fordistributed concurrent version management according to the embodiment ofthe present invention.

[0038] The method for distributed concurrent version management issuitable for use in a system with a first server having a file, a secondserver having a file copy corresponding to the file, and at least oneclient.

[0039] When the client wants to replace the file copy in the secondserver with an updated file, in Step S301, the connection status betweenthe first server and the second server is detected. If the second serverand the first server are connected (Yes in Step S302), the system timeis adjusted between the second server and the client. That is, the timeof the client is set as the system time of the second server.

[0040] Then, in Step S304, it is determined whether the file copy isaccessed by other clients. The procedure returns to Step S301 if so,otherwise, in Step S305, the file copy on the second server is replacedby the updated file, and in Step S306, a time tag according to theupdated system time is labeled after the file copy is replaced by theupdated file.

[0041] Thereafter, in Step S307, the time tag corresponding to theupdated file is compared to the time tag (new time tag) corresponding tothe file in the first server. Then, in Step S308, the updated file iscopied to the first server and the file is replaced by the updated fileif the time tag is later than the new time tag (Yes in Step S307).Otherwise, the updated file is not copied to the first server and thefile in the first server is not replaced by the updated file.

[0042] Further, in Step S309, it is determined whether the serverconnected by the client is the master server when the second server andthe first server are disconnected (No in Step S302). If the server isthe master server (Yes in Step S309), the procedure returns to StepS303; otherwise, goes to Step S311. In Step S311, if the client simplewants to read the file, the file is read (downloaded) by the client asthe client wants (Yes in Step S310).

[0043] For consistence of database file versions, when the master andsecondary server are disconnected, the master server may provide fullfunctions to clients but the secondary server only provides limitedfunctions, such as reading without updating.

[0044] It should be noted that the embodiment of present inventionmanages concurrent versions, that is, situations in which there areseveral versions of a file. The data type of a file in the concurrentfile versions management system includes version information, while thedata type of a file in the concurrent file management system does notcontain such version information. Similarly, the present invention maybe applied to the management of concurrent files and concurrent fileversions.

[0045] As a result, using the system and method for distributedconcurrent version management according to the present invention, theconsistency of file copies on different servers can be maintained, so asto reduce connection costs when accessing a single server.

[0046] Although the present invention has been described in itspreferred embodiment, it is not intended to limit the invention to theprecise embodiments disclosed herein. Those who are skilled in thistechnology can still make various alterations and modifications withoutdeparting from the scope and spirit of this invention. Therefore, thescope of the present invention shall be defined and protected by thefollowing claims and their equivalents.

What is claimed is:
 1. A system for distributed concurrent versionmanagement, comprising: a first server having a first database includinga file; a second server having a second database including a file copycorresponding to the file in the first database, a data replicationmodule, and a connection detection module to detect the connectionstatus between the first server and the second server; and a firstclient to replace the file copy in the second server with an updatedfile when the connection status is connected; wherein the updated fileis copied to the first server by the data replication module in thesecond server and the file in the first database is replaced by theupdated file.
 2. The system as claimed in claim 1 wherein system time isadjusted between the second server and the first client before the firstclient replaces the file copy in the second server with the updatedfile.
 3. The system as claimed in claim 2 wherein a time tag accordingto the adjusted system time is assigned after the file copy is replacedby the updated file.
 4. The system as claimed in claim 3 wherein thetime tag corresponding to the updated file is compared to a new time tagcorresponding to the file in the first server before the file isreplaced by the updated file, and the file is replaced by the updatedfile if the time tag is later than the new time tag.
 5. The system asclaimed in claim 1 wherein the first client can update the file copy inthe second server, but a second client cannot update the file in thefirst server if a disconnection status between the first and the secondserver is detected.
 6. The system as claimed in claim 1 wherein the fileis a source code file.
 7. The system as claimed in claim 1 wherein thefile is a file with a version data type.
 8. The system as claimed inclaim 7 wherein system time is adjusted between the second server andthe first client before the first client replaces the file copy in thesecond server with the updated file.
 9. The system as claimed in claim 8wherein the file is not replaced by the updated file if a time taglabeled after the file copy is replaced by the updated file is earlierthan a new time tag corresponding to the file in the first server. 10.The system as claimed in claim 7 wherein a second client cannot updatethe file in the first server while the file copy is being updated by thefirst client.
 11. The system as claimed in claim 7 wherein the firstclient can update the file copy in the second server, but a secondclient cannot update the file in the first server if a disconnectionstatus between the first and the second server is detected.
 12. Thesystem as claimed in claim 7 wherein the file is a source code file. 13.A method for distributed concurrent version management for use in asystem with a first server having a file, a second server having a copycorresponding to the file and a first client, comprising the steps of:detecting the connection status between the first server and the secondserver; replacing the file copy with an updated file from the firstclient when the connection status is connected; and copying the updatedfile to the first server by the second server and replacing the filewith the updated file.
 14. The method as claimed in claim 13 furtheradjusting system time between the second server and the first clientbefore the file copy in the second server is replaced by the updatedfile.
 15. The method as claimed in claim 14 further comparing a time taglabeled after the file copy is replaced by the updated file with a newtime tag corresponding to the file in the first server before the fileis replaced by the updated file, and replacing the file with the updatedfile if the time tag is later than the new time tag.
 16. The method asclaimed in claim 13 wherein the first client can update the file copy inthe second server, but a second client cannot update the file in thefirst server if a disconnection status between the first and the secondserver is detected.
 17. The method as claimed in claim 13 wherein thefile is a source code file.
 18. The method as claimed in claim 13wherein the file is a file with version data.
 19. The method as claimedin claim 18 further adjusting system time between the second server andthe first client before the file copy in the second server is replacedby the updated file.
 20. The method as claimed in claim 18 wherein thefirst client can update the file copy in the second server, but a secondclient cannot update the file in the first server if a disconnectionstatus between the first and the second server is detected.